1. Field of the Invention
The present invention relates to the field of IP Multimedia Subsystem (IMS) conferencing and, more particularly, to using a list management server for specifying conferencing participants in an IMS environment.
2. Description of the Related Art
A list management server creates and manages network-based group definitions and associated lists of members for defined groups. The list management server can maintain access lists, permissions, and other service specific properties associated with groups and group members. Use of a list management server permits a user's contact list, such as an email list of a personal address book, to be specified and used in an application independent manner. This can allow a user's contact list to be used by an email program at work and at home, by a mobile telephony device of the user, and the like. List management servers also support group list nesting so that one list can be referenced within another. The list management server further permits multiple users to share lists, such as sharing contact lists among employees in a company. Numerous standards exist to ensure compatibility of server managed lists, such as the XML Configuration Access Protocol (XCAP) standard of the Internet Engineering Task Force (IETF).
At present, list management servers are not used for conferencing purposes. Instead, communication conferences are typically implemented using proprietary software/hardware. For example, different service providers implement conferencing in a provider specific manner. This prevents applications from handling conferences in a unified manner, which can lead to incompatibilities. For instance, two partnering entities can be working together on a project which requires coordination with other entities. The partners can each coordinate with a set of contractors working on the project or a set of customers. Further, the partners can use different telecommunication service providers. When establishing conferences, each party can desire to handle its own contacts and to permit them to join a common conference, which many not be possible due to the proprietary manner in which each service provider handles conferences. It would be much more convenient if each partner could define a set of conference participants and then join these lists for a conference, which could be handled by either service provider. This is not currently possible. Conferencing capability problems will become increasingly significant in the future as different communication mediums converge and as expanded communication services are provided by different providers. For example, it is anticipated that future conferences can include participants using different participant selected interface modalities.
Conference centers have conventionally used proprietary hardware/software for implementing their functions. Contact centers, for example, often have conferencing capabilities where a supervisor is able to selectively join a live communication session involving a contact center agent and a caller. This conferencing capability is implemented in a vendor specific manner for vendor specific hardware and software, which results in a silo-ed solution. Different vendor solutions are incompatible with each other and other different capabilities. For example, one vendor may permit silent supervisor conferencing for monitoring purposes and a different vendor may permit a participating agent to add another agent to a session, such as when additional expertise is needed. Neither vendor may implement both agent directed conferencing and silent supervisor conferencing, which can be problematic for customers wanting both capabilities.